Support the authentication proofs of Symfony 8.2 - #322

Symfony 8.2 adds a "recent authentication" system to the Security component, and three of its pieces touch what this bundle decorates or replaces. This PR adapts the bundle to them while keeping it working unchanged on Symfony 7.4, 8.0 and 8.1.

What Symfony 8.2 adds (symfony/symfony#66064 has the whole design):

• IS_AUTHENTICATED_RECENTLY and IS_AUTHENTICATED_VERY_RECENTLY, decided by AuthenticationTrustResolver::isAuthenticatedRecently() / isAuthenticatedVeryRecently(). Both methods are declared on AuthenticationTrustResolverInterface as @method annotations; a resolver that does not implement them gets a deprecation and the attribute is denied ([Security] Decide IS_AUTHENTICATED_RECENTLY through the trust resolver symfony/symfony#66035, [Security] Add IS_AUTHENTICATED_VERY_RECENTLY, decided by the trust resolver symfony/symfony#66066).
• TokenInterface::getAuthenticationProofs() / setAuthenticationProofs(), a map of the authentication methods the user proved, as RFC 8176 amr values (pwd, otp, hwk, ...), to the time of the last proof of each. Also @method annotations in 8.2, implemented by AbstractToken; a token without them gets a deprecation and holds no proofs ([Security] Record which authentication methods were proven, and when symfony/symfony#66065).
• AuthenticationMethodBadge, which an authenticator adds to its passport to state which method it verified; the listener records it on the token, additively, so a second factor lands next to the password ([Security] Add AuthenticationMethodBadge, for an authenticator to state which methods it verified symfony/symfony#66069).

Why it matters for this bundle

1. Scheb\TwoFactorBundle\Security\Authentication\AuthenticationTrustResolver decorates security.authentication.trust_resolver and implements the three interface methods only. On 8.2 the voter therefore finds no isAuthenticatedRecently() on it, logs the deprecation and denies IS_AUTHENTICATED_RECENTLY for every application using the bundle. The two methods are added, delegating to the decorated resolver when it has them, and answering false for a TwoFactorTokenInterface, like isFullFledged() does.
2. TwoFactorToken implements TokenInterface directly with its own attribute bag, so it has no proofs. Since the bundle swaps the token on AuthenticationTokenCreatedEvent, the TwoFactorToken is what Symfony's listener sees when the first factor succeeds, and the password proof was lost. Both methods are added and delegate to the wrapped token, which is the one that ends up authenticated once 2fa completes.
3. The listeners that check the code add an AuthenticationMethodBadge once it is valid: otp for a backup code, or the method the provider says it verifies. That is a new optional AuthenticationMethodProviderInterface with one method, getAuthenticationMethod(): string, implemented by the TOTP, Google Authenticator and email providers (all return otp). A provider that does not implement it keeps working, and its proof is recorded as unspecified by Symfony.

With the three, a Symfony 8.2 policy can require a second factor, e.g. isset($token->getAuthenticationProofs()['otp']), which is the level-of-assurance use case the RFC describes.

Backward compatibility

• method_exists() / class_exists() guards everywhere the 8.2 API is used, so nothing changes on older Symfony versions; the added methods on the resolver and the token are plain additions.
• TwoFactorProviderInterface is untouched; the new interface is opt-in.
• The otp value for the email provider is a judgement call: RFC 8176 has no value for an emailed code, and otp ("one-time password") is the closest. mca (multiple-channel) would be the alternative if you prefer to distinguish it from an authenticator app.

The tests for the badge are skipped until AuthenticationMethodBadge exists in the installed Symfony version; everything else runs on 8.1. phpcs, psalm and php-cs-fixer are clean.